home *** CD-ROM | disk | FTP | other *** search
/ InfoMagic Internet Tools 1993 July / Internet Tools.iso / RockRidge / mail / pine / imap_archive / text0070.txt < prev    next >
Encoding:
Text File  |  1993-07-02  |  6.3 KB  |  134 lines
  1. Erik et al,
  2. Per your request, here is an IMAP charter with more concrete 
  3. milestones added.  (The rest of the text is unchanged.)
  4.  
  5. -teg
  6.  
  7. --------------------------------------------------------------------------
  8. 93.4.19
  9. teg
  10.  
  11. Interactive Mail Access Protocol Working Group (imap)
  12.  
  13. Chair:
  14.  
  15.      Terry Gray             gray@cac.washington.edu
  16.  
  17. Mailing Lists:
  18.  
  19.      General Discussion:    ietf-imap@cac.washington.edu
  20.      To Subscribe:          ietf-imap-request@cac.washington.edu
  21.      Mail archive:          ftp.cac.washington.edu /imap/imap_archive
  22.  
  23. Description of Working Group:
  24.  
  25. The Internet Interactive Mail Access Protocol (IMAP) working group is
  26. chartered to refine and extend the current IMAP2 protocol as a candidate
  27. standard for a client-server Internet email protocol to manipulate remote
  28. mailboxes as if they were local.  An explicit objective is to retain
  29. compatibility with the growing installed base of IMAP2-compliant software. 
  30. It is expected that the resulting specification will replace both RFC-1176
  31. and the more recent (as yet unplublished) IMAP2bis extensions. 
  32.  
  33. A mail access protocol provides a uniform, OS-independent way of
  34. manipulating message data (email or bulletin board) on a remote message
  35. store (repository).  Mail user agents implementing such a protocol can
  36. provide individuals with a consistent view of the message store,
  37. regardless of what type of computer they are using, and regardless of
  38. where they are connected in the network.  Multiple concurrent sessions
  39. accessing a single remote mailbox, and single sessions accessing multiple
  40. remote mailboxes are both possible with this approach. 
  41.  
  42. There are no Internet standards in this area, and one is needed to define
  43. a consistent approach to the problem in the context of other Internet mail
  44. protocols including RFC-822, SMTP, and MIME.  IMAP appears to be the only
  45. existing *open* protocol that achieves the above goals. Hence, the choice
  46. is either to invent a new protocol from scratch, or to refine IMAP2. 
  47. IMAP2 is in production use at a number of large sites, and several
  48. commercial products based on it are now available. Operational experience
  49. has been very positive, and the installed base is growing.  In the absence
  50. of any serious problems with the current specifications (IMAP2 plus
  51. IMAP2bis extensions), it makes little sense to start over, nor to abandon
  52. compatibility with the installed base. 
  53.  
  54. Comparison to POP.  There is a Draft Standard describing the latest
  55. version of the Post Office protocol (POP3, RFC-1225).  POP is a
  56. store-and-forward transport protocol that allows an MUA to retrieve
  57. pending mail from a mail drop (where it is then usually deleted
  58. automatically).  IMAP, in contrast, is focused on remote mailbox
  59. manipulation rather than mail transport.  Although IMAP is a functional
  60. superset of POP and can operate in the same mode, the two have different
  61. purposes and should not be viewed as competing. 
  62.  
  63. Comparison to PCMAIL.  PCMAIL, defined in RFC-1056, uses the Distributed
  64. Mail System Protocol (DMSP).  It has been relegated to Informational
  65. status by the IAB.  A strength of DMSP is support for "disconnected
  66. operation" wherein a local message cache can be created for off-line
  67. processing, and later resynchronized with the main mail server. 
  68. Preliminary discussions have taken place with members of the DMSP
  69. community on how to fold similar capabilities into IMAP2.  The working
  70. group will develop extensions to imap2 which provide a similar capability. 
  71.  
  72. Commercial alternatives. Many of the vendor-specific remote mail access
  73. approaches are based on proprietary remote file system protocols that
  74. neither scale well nor support diverse types of client operating systems. 
  75. Others are unsuitable candidates for Internet standardization due to
  76. licensing  restrictions.
  77.  
  78. Comparison with NFS.  Achieving many of the stated goals is possible using
  79. a generic remote file access protocol such as NFS, rather than an
  80. application-specific email protocol.  However, there are also some
  81. significant drawbacks, including: file locking on the mail server in the
  82. face of concurrent local and (possibly multiple) remote updates;  network
  83. performance; and difficulty in implementing on small client machines. 
  84. Moreover, using an application-specific protocol allows the server to
  85. provide more efficient caching, searching and message parsing.  The latter
  86. is particularly important in the context of MIME, so that the client can
  87. request message structure information from the server, and thereafter
  88. retrieve only the body parts it needs. 
  89.  
  90. Security.  Security-related tasks include how to incorporate secure
  91. authentication mechanisms when establishing a session, and possible
  92. interactions with Privacy Enhanced Mail. 
  93.  
  94. This working group's IMAP standardization activity complements (and does not
  95. compete with) parallel efforts to define the "IMSP" mail support protocol
  96. which will be layered on top of the resulting IMAP protocol.  The mail
  97. support protocol work addresses issues of managing large email sites, such
  98. as determining on which mail server a particular user's incoming mail
  99. resides.  
  100.  
  101.  
  102. Goals and Milestones:
  103.  
  104. It is expected that most of the work of this group will be conducted via
  105. email. Opportunities to meet face-to-face at IETF meetings will be used
  106. initially to review the charter and context for the work, as well as
  107. presentations to help members get up to speed on IMAP.  A goal is to have
  108. the IMAP2bis draft updated and submitted as an Internet draft in the July
  109. timeframe.  The November IETF WG meeting would then focus on detailed
  110. review of the draft standard. 
  111.  
  112. Mar 93 IETF   A BOF to review the working group charter, and discuss
  113.               its relationship to the broader remote mail issues
  114.               considered in previous IETF email BOFs.  
  115.  
  116. Jun 93        Submit Internet-draft, integrating RFC-1176 and IMAP2bis doc.
  117.  
  118. Jul 93 IETF   Foreign travel restrictions may preclude several of 
  119.               the key players from attending the Amsterdam IETF, however,
  120.               it may be possible to schedule a WG meeting for 
  121.               presentations and to solicit input from those who are 
  122.               normally unable to attend US IETF meetings.
  123.  
  124. Sep 93        Incorporate changes for disconnected service, etc, and 
  125.               submit as Proposed Standard.
  126.  
  127. Nov 93 IETF   Based on continuing email refinement of the text, and
  128.               implementation experience, use this meeting for a detailed 
  129.               review of Proposed Standard text.
  130.  
  131.  
  132.  
  133.  
  134.